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1.0 Introduction 

This report serves as an update about the activities of Stanford University's Space Systems 
Development Laboratory (SSDL) in their beacon-based health monitoring experiment. Section 1 
describes the goals of the project and the organization of the team. Section 2 provides an 
overview of the major components of the system, describing the general approach of automated 
health monitoring and the beacon signal relay. It also provides background about the 
SAPPHIRE spacecraft and ASSET operations system, which will be used for the experiment. 
Specific details about implementation and status of each element of the experiment are found in 
Section 3. Section 4 describes the experiment and future work, and references are contained in 
Section 5. 

1.1 General Goals 

The purpose of this project is to demonstrate the feasibility of a beacon-based health monitoring 
concept for spacecraft in low Earth orbits. This study is an element of ongoing research at SSDL 
in the areas of spacecraft systems engineering, automation and operations, and is supported in 
part by the New Millenium Program through JPL. 

Beacon-based health monitoring, within the scope of this project, is defined as a system wherein 
the routine task of anomaly detection is migrated from ground control to spacecraft control. The 
intent is to reduce operations costs by reducing both operator man-hours and the bandwidth 
necessary for ground-space communications. Fault isolation and recovery tasks are still 
performed by operators, however, and therefore it is necessary to develop methods to alert the 
mission control center of changes in spacecraft state requiring changes in the operations plan. 
The low-power, low-bandwidth beacon signal broadcast by the satellite announces the 
operational response required by the spacecraft at any given time. With very low-cost receiving 
stations, this signal can be relayed to mission control for proper, timely response. 

For this project, SSDL's SAPPHIRE spacecraft will be modified to perform automated anomaly 
detection to assess its health state. This very low-bandwidth signal (two bits) will be broadcast 
on an intermittent basis. Very low-cost (around $1000) receiving stations, under development at 
SSDL, will receive the signal, identify the spacecraft health state, and relay this information to 
SSDL s ASSET operations system. This system will automatically log the incoming message 
and take appropriate action, up to and including rescheduling the network and paging operators 
to prepare to recover a failed spacecraft. 


Once an end-to-end ground "proof of concept" test of the experiment is performed in December 
1997, this experiment will await the launch of SAPPHIRE sometime in 1998. Once on-orbit, 
this health monitoring concept can be experimentally tested by performing non-beacon and 
beacon operations. The operator man-hours and communications link bandwidth for each 
method will be compared; it is expected that beacon-based monitoring will result in significant 
reductions in bandwidth and operator effort, with no loss of spacecraft performance. 
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1.2 The Space Systems Development Laboratory 

Established in 1994, Stanford's Space Systems Development Laboratory was chartered to 
perform world-class research in all areas of spacecraft design, fabrication, and operations. The 
laboratory achieves these goals through classroom education, project experience, and student 
research. As part of the Masters degree curriculum, students can get involved in one of the lab's 
student-directed satellite projects. Two spacecraft, SAPPHIRE and OPAL, are currently in 
development. SAPPHIRE is further described in Section 2.3. 

One of the primary areas of research in SSDL is in the area of spacecraft operations and 
automation. The beacon-based health monitoring experiment described in this paper is one of 
their main projects, and is being used to integrate the Automated Space Systems Experimental 
Testbed (ASSET) system, further described in Section 2.2. 

For the beacon experiment, the following students and faculty are involved: 

Professor Robert Twiggs (SSDL Director): Project Oversight 

Christopher Kitts (PhD Candidate, Mechanical Engineering): Project Oversight, ASSET System 
Architecture, SAPPHIRE Operations Lead 

Michael Swartwout (PhD Candidate, Aeronautics & Astronautics): Project Oversight, ASSET 
Software Programming, SAPPHIRE Project Manager 
Brian Engberg (PhD Candidate, Aeronautics & Astronautics): ASSET Scheduling, SSDL 

Ground Station Manager 

Carlos Niederstrasser (Engineers Candidate, Aeronautics & Astronautics): Beacon Receiving 
Station 

Raj Batra (PhD Candidate, Aeronautics & Astronautics): SAPPHIRE Software Lead 

1.3 Academic Contributions 

The work performed on this project has resulted in many papers and conference publications. 
Most notably, Kitts and Swartwout presented their "Beacon Monitoring System for Automated 
Fault Management Operations" paper at the 1996 AIAA/USU Conference on Small Satellites in 
Logan, Utah; the follow-up report, "Automated Health Operations for the SAPPHIRE 
Spacecraft" will be presented at the 1997 International Telemetering Conference in Las Vegas, 
Nevada. The special software needed for this mission was described in Batra's "Designing a 
Flexible Operating System for SQUIRT Spacecraft" at the 1997 AIAA/USU Conference on 
Small Satellites. Two more papers, Kitts' "An Advanced Client Interface for Requesting Space 
Mission Products" and Swartwout's "Approaches to Engineering Data Summary for Space 
Missions" will be presented at the 1998 IEEE Aerospace Conference in Colorado. All of these 
papers are listed in Section 5. 

The results of the proof of concept experiment will be presented at the 1998 SpaceOps 
conference in Tokyo. Moreover, the beacon-based health monitoring concept and experiment 
directly contributes to the PhD dissertations of Kitts (June 1998) and Swartwout (October 1998), 
and the Engineer's Degree thesis of Niederstrasser. 
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2.0 Project Outline 

System health management is a specific mission operations task that has been enhanced through 
the use of automation technologies. The space industry routinely uses ground based expert 
systems to analyze spacecraft telemetry and detect the existence of faults. While this model has 
proven to be beneficial in reducing the workload of human controllers during nominal 
operations, it still requires full use of scarce ground equipment and bandwidth resources in order 
to deliver spacecraft telemetry to the control center. 

To address this drawback, many developers in the spacecraft community advocate the migration 
of detection capability from the ground to on board the spacecraft. This new model requires the 
on-board reasoning system to perform realtime health assessment and to use a "beacon" to report 
the vehicle's status to the mission control center. Composed of, at most, a few bits of 
information, this beacon signal will summarize the spacecraft's status. When healthy, a 
"Normal" or "I'm OK" signal will reduce the need for routine health assessment contacts thereby 
conserving resources. When a fault exists, an "Emergency" or "Help Me" signal will trigger 
notification of controllers and can be used to initiate a variety of contingency operation 
functions. 

While promising significant reductions in the cost of staffed operations and the time to detect 
and respond to a fault, the health monitoring beacon model of fault detection poses a number of 
additional design challenges. To prove the value of the beacon monitoring concept, SSDL is 
preparing to conduct a real world evaluation through the use of microspacecraft and a global, 
automated space operations network. This approach consists of automated fault detection on 
board a spacecraft, a state of health beacon signal broadcast by the spacecraft, a ground based 
monitoring network, and a mission control center capable of efficiently integrating this health 
assessment strategy into its operating architecture. 

The experiment will be performed using the SAPPHIRE spacecraft, under development by 
SSDL, using the automated beacon receiving station and the mission control system at Stanford 
University. Each aspect of the project is introduced in this section, with implementation details 
provided in Section 3. Section 4 describes the tests that will be performed to demonstrate the 
concept and verify the performance 

2.1 Beacon-Based Health Management Overview 

A brief overview of the health monitoring beacon signal flow is presented here and shown in 
Figure 1. SAPPHIRE will monitor its own telemetry sensors, comparing measured values with 
commandable entries in a state-dependent limit table. Depending on the seriousness of the limit 
violation, the spacecraft health is assessed to be one of four values. The health beacon is 
transmitted by SAPPHIRE’S main transmitter. Simple, receive-only stations will listen for 
SAPPHIRE beacon transmissions and notify mission control of the results by electronic mail. 
These stations will be in locations around the world, giving SAPPHIRE (and other spacecraft in 
the network) near-global coverage for health monitoring. 
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In this manner, all spacecraft sensor data is compacted into a few bits that tell an operator 
whether or not SAPPHIRE can continue to perform its mission. And while such information 
once had to be collected over time for eventual download and processing at mission control, 
spacecraft health is now continuously monitored and available anytime the spacecraft is within 
range of a low-cost receiving station. Once mission control receives a beacon monitoring update 
from a remote station, it logs this information and then takes appropriate action. Depending on 
the health assessment, there are varied responses, from storing the update in the system database 
to paging the operator on call, and rescheduling the network to contact the satellite. 
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Figure 1: SAPPHIRE Health Beacon Signal Flow 
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The health monitoring beacon experiment is the first implementation of the Automated Space 
Systems Experimental Testbed (ASSET) system under development at Stanford University. The 
primary goal of this system is to enable low-cost and highly accessible mission operations for 
SQUIRT microsatellites as well as other university and amateur spacecraft. The second goal of 
this system is to serve as a comprehensive, low inertia, flexible, real-world validation testbed for 
new automated operations technologies. Figure 2 shows a high level view of the ASSET mission 
architecture. The basic components include the user interface, a control center, ground stations, 
communications links, and the target spacecraft. During the current developmental phase, a 
highly centralized operations strategy is being pursued with nearly all mission management 
decision making executed in the control center. These tasks include experimental specification, 
resource allocation throughout the ground and space segment, health management, contact 
planning, data formatting and distribution, and executive control. 

Mission operations elements, such as experiment requests, planning, scheduling and health 
management are automatically handled in ASSET through a blackboard system. A blackboard 
system is a software architecture wherein all the problem-solving elements, or knowledge 
experts, collaborate to solve the global task by working on a collective database, or blackboard. 
ASSET'S blackboard system is a modified version of BBK, whose source code is freely 
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distributed by its developer, Dr. Barbara Hayes-Roth of Stanford's Knowledge Systems 
Laboratory. 
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Figure 2: The ASSET Space System Architecture 


2.3 The SAPPHIRE Spacecraft 

SAPPHIRE is a student-designed, student-built 
spacecraft that is fully functional and is nearing the 
end of its environmental acceptance tests. The 
spacecraft will be ready to launch in the first quarter 
of 1998, some four years after a nearly all-volunteer 
group of spacecraft design novices took up the task 
of building a satellite given less than $50,000 for all 
parts and testing. 



Figure 3: The SAPPHIRE Spacecraft 


SAPPHIRE is an acronym for Stanford 
AudioPhonic PHotographic InfraRed Experiment. 

Those letters describe the three instrument-based 
missions of this project. The infrared detectors are a 
next-generation micromachined horizon detector, operating at room temperature at about one 
Watt. A voice synthesizer broadcasts an FM "computerized" voice. A digital camera takes 
pictures of the Earth. In addition, several other missions advance basic research in spacecraft 
automation and operations, including the beacon-based health management described in this 
report. But SAPPHIRE'S primary mission is to train students in all aspects of spacecraft design, 
fabrication, testing and operations. 
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Shown in Figure 3, SAPPHIRE is a hexagonal cylinder made from aluminum honeycomb, 17" 
from tip to tip and 13" tall (including launch interface). It has a total launched mass of 18kg (40 
pounds) and is seeking secondary launch opportunities. The spacecraft is passively stabilized to 
follow the Earth's magnetic field, with a slight spin about its top axis. It communicates on the 
70cm and 2m Amateur Radio bands. The operator software is student-written for the MC68332 
microcontroller, acting as a UNIX-like bulletin board system. The design emphasizes the use of 
commercial, "off-the-shelf' parts. 

When the spacecraft is unavailable for development - due to thermal vacuum testing or other 
circumstances - testing will be performed on "A1 Wood", SAPPHIRE'S fully functional 
prototype. A1 Wood is equivalent to SAPPHIRE in all aspects save environmental packaging 
and will be available for use even after SAPPHIRE has been launched. 

3.0 Project Status 


The beacon-based health monitoring experiment has been divided into several portions. The five 
elements are: Health Assessment, Beacon Broadcast, Beacon Receiving Station, Automatic 
Notification, and System Resource Allocation. Table 1 gives a brief description of each element 
and its implementation status. "Delivery" indicates when a version of that element will be ready 
for the proof of concept test. All elements are further described, below. Note that the section 
headings include the names of the students responsible for providing that element. 
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Table 1: Beacon-based Health Management Elements 
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3.1 Health Assessment (Kitts/Swartwout/Batra) 

SAPPHIRE has two operating modes, Normal and Safe. Normal Mode allows foil use of all 
payloads and functions aboard the spacecraft, within the usual restrictions governed by the user's 
login status. Safe Mode is intended to protect the spacecraft from mission-threatening conditions 
such as low battery voltage; entering Safe Mode causes all payloads to be turned off, all users to 
be logged off, and access restricted to a single "root user" - the SSDL mission operations team. 
The spacecraft remains in Safe Mode until the root user resets it to Normal Mode. 

Given these two operating modes, four spacecraft health states are defined. These states map 
directly to the classes of responses an operator would take, and they are described in Table 2. If 
all components on the spacecraft are determined to be functioning normally - all sensors are 
within their defined limits - the health assessment is determined to be Normal. Abnormal health 
means one or more sensors are in their "yellow limits", which is a condition the operators should 
be aware of but which does not immediately threaten the health of the spacecraft. (Or, as is often 
the case for SAPPHIRE, it indicates an out-of-limits state that is not easily controllable by 
ground command.) Critical health indicates a vital components is dangerously out-of-limits, 
such as low battery voltage; the spacecraft CPU will put itself into Safe Mode as described 
above. When power cycle or radiation hit causes the CPU to reses, it boots up in the Emergency 
health state; this unexpected reset calls for different operational procedures than for Safe Mode. 
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Table 2: SAPPHIRE Beacon States and Vehicle Modes 

SAPPHIRE contains 32 analog sensors, measuring such items as battery voltage, solar panel 
currents, transmitter temperature and payload sensor outputs. These measurands, and their high 
and low limits, are detailed in the Appendix. In addition, the operating system allows for 32 
"customizable sensors." These are essentially counters to track user-defined variables. 

Health monitoring is performed once every minute using a table system that is native to the 
spacecraft operating system. Table rows can be added or deleted and new tables can be created 
according to uploaded commands. A table row contains the identifier of the sensor to be 
examined, the upper and lower limits of the sensor, the persistence counter for this sensor, and 
the actions to take should the sensor be deemed out-of-limits. A sample table is presented in 
Table 3. First the CPU temperature and battery voltages are tested against the "Abnormal" 
limits; for each component that is assessed to be out of limits, a user-defined counter is 
incremented. Then, the battery voltage is checked again against its "Critical" limits and the 
appropriate counter may be incremented. Finally, the "Critical" counter is checked; if even one 
component has been found to be in a critical state, a string of actions are implemented to put the 
spacecraft in Safe Mode. 
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Table 3: Sample Health Assessment Table 

The concept of persistence has been included to account for sensor noise and to avoid rapid 
changes in state due to a sensor cycling near the limit boundaries. For a measurand to be 
considered "out of limits", it must persist in exceeding the designated bounds. A counter keeps 
track of the number of samples the measurand is too high or low, incrementing or decrementing 
as appropriate. When the counter matches the persistence value, the measurand is considered to 
be out of limits. The same holds true for the reverse; a measurand must persist inside the limits 
before it is considered to be normal again. 

The limit values are commandable so that analysis can evolve with normal operating conditions. 
For example, solar panel current limits will be modified over time so that solar cell degradation 
will not be detected as a fault. In addition, the SAPPHIRE limit checking system can operate at 
an aggregate level in order to provide more focused analysis. For instance, the current from a 
single solar panel will typically vary between zero and some maximum normal level of output. 
An additional and much stronger check can be made, however, by ensuring that not all solar cells 
are near their maximum level, since SAPPHIRE'S geometry prevents the sun from illuminating 
all panels at once. Finally, SAPPHIRE'S limit checking is context sensitive so that different 
expected ranges are applied to realtime telemetry based upon the estimated state of the vehicle. 
An example of this is that during an eclipse the battery should be discharging. This approach is 
implemented by creating different tables for eclipse conditions and sunlight conditions; an 
assessment is made first to determine whether the spacecraft is in sunlight or eclipse and then the 
appropriate table is used. 

A strawman anomaly detection simulation was developed and tested in the summer of 1996. The 
concept for the flight software implementation has been developed and was approved in August 
1997. Preliminary work has been completed on the flight software commands. This software is 
currently being written and added to the flight code. It is expected that a functional version of 
the health monitoring code will be tested in October 1997. 

3.2 Beacon Broadcast (Swartwout/Batra/Niederstrasser) 

The spacecraft health state is then broadcast as a low-power, low-data-rate beacon. For 
Sapphire, the four possible health states can be expressed in a two bit signal. The beacon 
transmits this signal on a frequent (every one to two minutes) basis. The signal will be broadcast 
on SAPPHIRE'S transmitter frequency, 437.100 MHz (70cm band). 
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Exact specifications for the beacon broadcast are still being determined; SAPPHIRE can 
implement the beacon digitally through a feature of its on-board radio modem, or pseudo- 
digitally by pulse modulation of the transmitter's carrier wave using the voice synthesizer 
payload. The pseudo-digital signal can be interpreted by a digital signal processor, converting 
the pulse modulation to ones and zeroes. Final decision on the mode of implementation requires 
a trade study involving spacecraft power consumption and duty cycle, complexity of generating 
the pulse modulation, and receiver link budget. This work will be completed in November 1997. 

For prototype development, a simple ASCII beacon was implemented in June 1996 using the 
capabilities of SAPPHIRE'S radio modem, and is still available for use. 

3.3 Beacon Receiving Station (Niederstrasser) 

The next stage of the monitoring system is the reception of the beacon signal. Except for the 
times when SAPPHIRE is in contact with ground operators, the beacon is broadcasting. Simple, 
receive-only, HAM radio frequency stations are being designed to acquire the two-bit beacon 
signal. These stations will accommodate multiple vehicles and will forward received signals to 
mission control centers through Internet or modem connections. Primary development of the 
receiving station for the SAPPHIRE/ASSET experiment is being conducted at Stanford 
University; educational initiatives have been established with Tuskegee University, Montana 
State University, and the Space Engineering School in Kiruna, Sweden to create a global 
network. 

The receiving station is in the developmental stage, but basic requirements have been identified. 
Each station is intended to be low-cost ($1000) and operationally autonomous; the station does 
not track the spacecraft, nor does it require an operator to activate the receiver, interpret the 
incoming signal, or relay the information to the ASSET mission control. A functional prototype 
will be available in December 1997. 

3.4 Automatic Notification (Swartwout) 

When the mission control center receives an update from the remote receiving station, a series of 
actions take place. First, this message is automatically logged in the system database. Next, the 
content of this message is analyzed for pertinent data. If the health state indicated for that 
particular spacecraft warrants further action, the scheduling system of ASSET is notified, and an 
operator may also be paged. 

These tasks have been implemented by a set of C functions running on a UNIX platform. As 
shown in Figure 4, A single process checks for incoming mail, parses the beacon messages, 
stores the information in the system database, and looks for alarms. If an alarm is detected, it 
sends a message (via a UNIX socket) directly into the scheduling system of ASSET (see below). 
Alarms of a serious nature (requiring prompt operator action) cause this process to send 
electronic mail to the operator. Several commercial Internet service providers can link a pager to 
an electronic mail account, allowing for near-instantaneous operator notification. 


- 10 of 10- 



Prepared 9/30/1997 



Operator Notification 
(■ electronic mail) 


Figure 4: Automatic Notification Schematic 


This element of the health monitoring system was demonstrated in June 1997 during a visit to 
JPL by members of the SSDL team, and is ready for the end-to-end test. 


3.5 System Resource Allocation (Kitts/Engberg/Swartwout) 

The final element of the health monitoring system is prepare the operations network to service 
this spacecraft. A Normal health state requires no changes, of course, since the operations plan 
assumes normal state. For SAPPHIRE, the Abnormal state involves minimal changes in 
operations, since operators have little or no controllability of the components involved in 
determining the Abnormal conditions. Beyond flagging a note for operators, no response is 
needed. 

If SAPPHIRE'S health state is either Critical or Emergency, a number of more involved functions 
are performed. First, SAPPHIRE experiments are postponed or canceled. Second, ground 
station support for SAPPHIRE is scheduled. Third, the schedules of other ASSET spacecraft are 
reworked to account for changes in ground station availability and experimental loading. 

The ASSET blackboard system is in development, with a basic scheduling system currently 
undergoing testing. This scheduler, when implemented, will allow for a functional 
demonstration of the responses ASSET takes to a health emergency. This element will be ready 
for functional demonstrations in December 1997. 

Although not formally part of the initial SAPPHIRE/ASSET beacon system, automated 
documentation retrieval and advanced fault isolation, diagnosis, and recovery techniques are 
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being developed in order to aid the operator once full fledged contingency analysis begins. This 
capability is essential to the success of the beacon concept since operators will not be intimately 
famili ar with spacecraft behavior once automated fault detection capability is established and 
trusted. In later versions of the beacon system, on-board health summarization will be included; 
this will enable the advanced documentation and health management functions to be integrated 
directly into the overall beacon monitoring system. 

An open issue in the design of ASSET'S response is how to deal with on-board mission data 
when the CPU initiates a vehicle Safe Mode. All of SAPPHIRE'S data is stored in active 
memory; should the CPU reset, all data is lost. ASSET must terminate active experiments or 
reschedule them to collect data that was lost. But in a CPU initiated Safe Mode, the data is likely 
to still be on board and intact. Because of fault analysis and recovery requirements, there may be 
some time before this data can be returned to the control center, or it may be lost during the 
recovery process. To ignore data that is available, however, is an inefficient use of limited 
spacecraft and ground resources. The trade, then, is to determine the conditions under which the 
data "trapped" on Sapphire should be salvaged or given up for lost. This issue is being resolved 
through experimentation and assessment of the beacon system. 

4.0 Future Work 

The immediate goal of this project is to prepare all the elements for an end-to-end test; this will 
serve as a proof of concept. The next step is to demonstrate that this approach is an 
improvement over normal, operator- and contact-intensive operations by reducing the man-hours 
needed for operations and conserving communications bandwidth. This validation can be 
initially performed with SAPPHIRE operating in SSDL's clean room. Full validation will be 
performed once SAPPHIRE is in orbit. Exact details of these tests can be found in the Beacon- 
Based Health Monitoring Requirements Document and Design Document, referenced below. 

4.1 Timeline to End-to-End Test 

As explained in Section 3, the next major step in the project is to implement and test the added 
features of the flight software. This will take place in October 1997. Simultaneously, a first-cut 
version of the scheduling software is being developed; this will allow a functional demonstration 
of ASSET'S ability to automatically reschedule in the event of a health emergency. 

Once these two elements are functional, an initial demonstration of the system is possible. A text 
beacon is already implemented on the spacecraft; the messages can be read when the ground 
station is listening on that frequency. Thus, the spacecraft can automatically generate beacon 
messages; a human operator is needed to decipher and manually send the electronic mail update 
to the ASSET control center. The logging, notification, and replanning tasks will be 
automatically performed. 

The final element is the beacon receiving station. Since Stanford took the development lead of 
this element only recently, it is still in the tradeoff stage. Expectations are high for rapid 
development and a working prototype by early December. Once the receiving station is 
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functional, it will be inserted into the rest of the system and a complete end-to-end demonstration 
will take place in December 1997. 

4.2 Ground Tests of Validation Experiment 

Once SAPPHIRE is fully ready for flight, it will be locked away inside SSDL's clean room for 
no less than thirty days of operational checkout. Since the health monitoring beacon experiment 
is one of SAPPHIRE'S missions, there will be time to perform demonstrations and tests of the 
concept in flight-equivalent conditions. SAPPHIRE will remain operational from inside the 
clean room while it waits for a secondary launch, so there could be significant time available for 
ground tests of the validation experiment. 

4.3 Flight Validation 

Once the spacecraft passes initial checkout and data for the THD primary payload has been 
sufficiently collected, this beacon-based health monitoring concept will be tested. First, data will 
be taken for a "routine" week of operations, keeping track of the number and duration of contacts 
required to perform health management tasks. The time spent by operators in performing these 
tasks will also be recorded. Then the health monitoring beacon system will be activated and the 
same information will be collected. 

Provided that the spacecraft has the same general performance during these two weeks, such as 
similar duty cycles for instruments and similar numbers and types of anomalies, a comparison 
can be made regarding the cost of performing beacon-based health management. Again, it is 
expected that the cost of operations, as measured by operator man-hours and communications 
bandwidth, will decrease. Given that identical methods for anomaly detection will be used in the 
ground-based and space-based cases, there is no projected improvement in the quality of 
prediction, though tests can also be run on this subject; there may be some improvement due to 
the fact that the on-board anomaly detection occurs much more frequently than is possible on the 
ground. For the same reason, the response time to an anomaly may also decrease, but there are 
complex effects related to paging an operator from outside the mission control center, and also 
the time required for an operator to get "up to speed" on the state of the spacecraft. 

4.4 Additional Studies 

Of course, the issue raised at the end of Section 4.3 warrants further investigation. Operators 
used to be very familiar with the spacecraft they monitored - or they had an extensive historical 
telemetry archive to allow them to get familiar with the performance of every component. 
However, in beacon-based health management the spacecraft is responsible for the routine 
sensor analysis, which means that the telemetry data is rarely, if ever, sent to the ground. 
Reduced bandwidth is, of course, one of the primary goals of beacon-based monitoring. 

Without this historical archive, it is necessary to provide other means of providing operators with 
the information necessary to perform health management duties. One possible solution has been 
termed the engineering data summary, which is already under investigation at JPL and other 
institutions. The idea is to perform additional on-board analysis to provide a summary of the 
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vital information about spacecraft components that will aid operators in performing complex 
tasks like anomaly isolation and fault recovery. Research continues at SSDL into developing 
solutions to this problem. As time and on-board memory allows, SAPPHIRE will be used as a 
testbed for data summary approaches. 

The ASSET system was conceived to allow rapid prototyping of different concepts for all 
aspects of spacecraft operations. It is a research tool that will allow beacon, summary, and other 
approaches to be tested in a real-world environment. 
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Appendix: SAPPHIRE Telemetry Information 


Each of SAPPHIRE'S 32 sensors are listed, along with its expected high and low values for both 
Critical and Abnormal states, plus some of the 'custom' channels. Note that many sensors do not 
have values for Critical; this is because those components do not pose a threat to the health of the 
entire spacecraft and/or there is no means to control their output through ground commands. 
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I SP 2 Current 
| SP 1 Current 
j SP 4 Current 
| SP 3 Current 
(Battery 2 Temp 
(Battery Voltage 
| SP 6 Current 
| SP 5 Current 
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)SP 8 Current 
| SP 7 Current 
(Battery Charge 
| Battery Current 
| Earth Sensor A 
1 Earth Sensor B 
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|THD 1 High Voltage 
ITHD 1 Temperature 
I THD 0 Signal 1 
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I®SS1tHD0 Temperature 

1 Fo toman Temp 
| Transmitter Temp 
| SP 8 Temperature 
1 SP 1 Temperature 
) SP 7 Temperature 
! SP 4 Temperature 
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CPU Temperature 
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te|3^fP Sunlit Panel Counter 
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W§i Critical Counter 
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